home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄23⁄90 / 0738-Re[2] Persistent…-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-23  |  1.9 KB  |  46 lines  |  [TEXT/GEOL]

  1. Item    4434659                         22-Feb-90        11:19PST
  2.  
  3. From:   ALGER                           Alger, Jeff,VCA
  4.  
  5. To:     MUYSVASOVIC                     ACE - Jean-Denis Muys-Vasovic
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: Re: Persistent…
  10.  
  11. Jean-Denis,
  12.  
  13. To respond to the issues you raised:
  14.  
  15. 1. TList et al must provide explicit support for the ownership (or lack
  16. thereof) of their referenced objects.  It would seem reasonable to have two
  17. versions (subclasses): one of which owns its objects and one of which does not.
  18. Again, I must emphasize that default behavior must be overridable!  This is one
  19. example of why: Object Pascal does not support collections in the language,
  20. therefore it is up to classes to do their own dirty work.  OP can only help
  21. with information it is given.
  22.  
  23. 2. In you hypothetical example, I would say that the document owns the new
  24. thing.  The TCommand could request that the document get rid of it, but the
  25. document itself should do the freeing.  (You left out in your sample code a
  26. call to the document to remove it from the TList.  This could have done the
  27. freeing.)
  28.  
  29. On a more general note before the links start rolling in: yes, ownership is not
  30. a cut and dried issue.  There are PhD theses written on the topic in database
  31. circles.  However, that should not stop one from creating generally useful
  32. default behavior.  Most ownership is straightforward and one of two types:
  33.  
  34. • Parent-child ownership.
  35. • Existence constraints (X ceases to exist when no one refers to it anymore.)
  36.  
  37. The latter is garbage collection, as you properly point out.  The former
  38. involves capturing more semantic information about the data and is the real
  39. object of my suggestion.  In any case, this is made all the easier to address
  40. because this is OOP: default behavior which does not fit the circumstances can
  41. be overridden.
  42.  
  43. Jeff Alger
  44. KPMG Peat Marwick
  45.  
  46.